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METHOD, SYSTEM, AND PRODUCT FOR A JAVA-BASED DESKTOP TO 
PROVIDE WINDOW MANAGER SERVICES ON UNIX 

BACKGROUND OF THE INVENTION 

5 

1. Technical Field: 

The present invention relates generally to data 
processing systems. More particularly, the present 
invention relates to a method, system, and product for 
10 managing window services in order to present the same 

graphical user interface to native UNIX applications and 
© Java applications in a computer system executing a 

\\ UNIX-based operating system and a Java desktop. 

U1 IS 2. Description of Related Art: 

sTI Computer systems often utilize a graphical user 

=* interface to present information to users. The graphical 

S user interface represents icons, window frames, menus, 

dialog boxes, and other items on a computer system's 
20 display screen. Users are more efficient when computer 
M a systems utilize a consistent graphical user interface 

(GUI) to present information. 

In current embodiments, UNIX window managers provide 
both the look of the desktop, by rendering the desktop 
25 background, icons, and other desktop elements, and the 
feel of the desktop, i.e. its behavior. They also have 
responsibility for the rendering and user interaction 
with the frame windows attached to applications. 

A problem arises, however, when creating a new 
30 desktop that is written in Java which desires to manage 
the look and feel of the desktop. The Java Virtual 
Machine and its libraries are not designed to fulfill the 
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responsibilities that a window manager has to native UNIX 
applications. For example, without a window manager to 
provide frame window support, native applications will 
not have frame windows. 
5 Figure 1 depicts a computer system 100 executing 

either an OS/2 or a Windows operating system 102, a 
desktop 104, and applications 106 in accordance with the 
prior art. OS/2 is a trademark of International Business 
Machines. Windows is a trademark of Microsoft 
10 Corporation. Applications executing on these platforms 
manage their own frame windows, obviating the necessity 
of the Java desktop to provide these capabilities in 
system 100. 

Figure 2 illustrates a computer system 200 executing 

15 a UNIX-based operating system 202, a desktop 204 

implemented in the C language, a window manager 206, and 
UNIX applications 208 written for a UNIX-based operating 
system in accordance with the prior art. Window manager 
206 provides a frame window and handles the interaction 

20 between the frame windows and the desktop for 

applications 208. Unix-based operating system may 
include any UNIX operating system, such as AIX. 

Figure 3 depicts a computer system 300 executing a 
UNIX-based operating system 302 and having a Java desktop 

25 304 in accordance with the prior art. Java, originally 
developed by Sun Microsystems, is an object-oriented, 
multi- threaded, portable, platform-independent, secure 
programming environment used to develop, test, and 
maintain software programs. Java programs have found 

30 extensive use on the Internet. These programs include 
full-featured interactive, standalone applications, as 
well as smaller programs, known as applets, that run in a 
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Java-enabled Web browser or applet viewer. 

A window manager, however, is not provided in 
computer system 300. When native UNIX applications are 
executed on computer system 300, the application client 
5 area will be displayed, but no frame window will enclose 
the client application area. This behavior would be 
considered faulty by an end user of this system. 

Computer system 300 could have an existing window 
manager added that would provide the frame window 
10 rendering and interaction, but this would introduce two 
desktop features into the system, i.e. the native window 
manager and Java desktop, and these two desktop features 
could present conflicting GUI characteristics to the end 
user. 



graphical environment is based on a client/server window 
system known as X Windows, initially developed at the 
Massachusetts Institute of Technology. X Windows 
provides a protocol for the client and server portions of 

20 an application to communicate with each other for display 
and input. An X Windows application consists of an 
application client area that is rendered by the 
application, and a frame window that is rendered and 
managed by the window manager. Events related to the 

25 application client window are handled by the application. 
Events related to the frame window are handled by the 
window manager. 

Therefore, a need exists for the function of the 
window manager to be distributed between a Java desktop 



30 / manager and a window manager proxy focused on the 
; management of message passing between applications 



requiring window manager services and the Java desktop 
manager in a computer system executing a UNIX-based 
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operating system with a Java desktop, but having no full 
featured window manager. 
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SUMMARY OF THE INVENTION 



A window manager proxy method, system, and product 
are described allowing a Java based desktop to provide 
5 window manager services on UNIX. A computer system 
executes a UNIX-based operating system and a desktop 
implemented in Java. The computer system does not 
include a separate window manager. Java applications are 
presented by the computer system utilizing a graphical 

10 user interface. Native UNIX applications are also 
presented by the computer system utilizing the same 
graphical user interface. Native UNIX applications 
interact with the window manager proxy in the same manner 
in which they would interact with a traditional window 

15 manager. The window manager proxy forwards frame window 
. activity related to the desktop to the Java desktop, and 
is the native interface from the Java desktop to the 
native platform for frame window activities. Native UNIX 
applications, Java applications, and the Java desktop are 

20 thus rendered and managed in a consistent manner 
providing the end user with the look and feel as 
configured within the Java desktop. 

The above as well as additional objectives, 
features, and advantages of the present invention will 

25 become apparent in the following detailed written 
description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
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The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

Figure 1 depicts a computer system executing either 
an OS/2 or a Windows operating system, a desktop, and 
applications in accordance with the prior art; 

Figure 2 illustrates a computer system executing a 
UNIX-based operating system, a desktop implemented in the 
C language, a window manager, and UNIX applications 
written for a UNIX-based operating system in accordance 
with the prior art; 

Figure 3 depicts a computer system executing a 
UNIX-based operating system and having a Java desktop in 
accordance with the prior art; 

Figure 4 depicts a pictorial representation of a 
networked data processing system in which the present 
invention may be implemented; 

Figure 5 illustrates a block diagram of a data 
processing system which may be implemented as a server in 
accordance with the present invention; 

Figure 6 illustrates a block diagram of a data 
processing system which may be implemented as a client in 
accordance with the present invention; 

Figure 7 depicts a computer system executing a 
UNIX-based operating system, a Java desktop, a window 
manager proxy, and native UNIX applications in accordance 
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with the present invention; 

Figure 8 illustrates a graphical window which may be 
displayed on a display screen to a user in accordance 
with the present invention; 
5 Figure 9 is a high level flow chart which 

illustrates the startup process* for the Java desktop with 
the window manager proxy in accordance with the present 
invention; 

Figure 10 is a high level flow chart which depicts a 
10 process followed when a native application is launched in 
accordance with the present invention; 
r*i Figure 11 is a high level flow chart which 

jP illustrates the execution flow of a Java desktop managing 

W 

user interactions with a frame window in accordance with 

X 15 the present invention; and 

%£} Figure 12 is a high level flow chart which depicts 

^ the execution flow for actions initiated programmatically 

£} through the window manger proxy from a native UNIX 

I* application, including events forwarded to the Java 

LT1 20 desktop, in accordance with the present invention. 

O 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A preferred embodiment of the present invention and 
its advantages are better understood by referring to the 
5 figures, like numerals being used for like and 
corresponding parts of the accompanying figures. 

The invention is preferably realized using a 
well-known computing platform, such as an IBM RS/6000 
workstation running the IBM AIX operating system. 
10 However, it may be realized in other popular computer 
system platforms, such as an IBM personal computer 
running the Microsoft Windows operating system or a Sun 
Microsystems workstation running operating systems such 
as UNIX or LINUX, without departing from the spirit and 
15 scope of the invention. 

The present invention is a window manager proxy and 
a Java desktop capable of rendering and managing frame 
windows for X Windows applications. The window manager 
proxy and Java desktop execute within a computer system 
20 which is executing a UNIX-based operating system. The 
computer system does not include a separate window 
manager. 

Native UNIX X Windows applications consist of an 
application client window rendered by the application and 
25 a frame window surrounding the application client window 
rendered by a window manager. In this invention, the 
function of the window manager is distributed between the 
window manger proxy and the Java desktop. The Java 
desktop is responsible for rendering the frame window and 
30 managing frame window events. The window manger proxy is 
the communication channel through which the application 
and Java desktop communicate. Native application client 
window events are executed in their native form, 
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unaltered. 

Whether an application is a Java application or a 
native UNIX application, the Java desktop provides the 
frame window, and supports a particular graphical user 
5 interface. When a native UNIX application generates 
native events, the window manger proxy forwards these 
events to be handled by the Java desktop. In this 
manner, native UNIX applications and Java applications 
are presented utilizing the same graphical user 

10 interface. Both application types are presented with the 
same look and feel. 

With reference now to the figures, and in particular 
with reference to Figure 4, a pictorial representation of 
a networked data processing system is depicted in which 

15 the present invention may be implemented. Networked data 
processing system 400 is a network of computers in which 
the present invention may be implemented. Networked data 
processing system 400 contains network 402, which is the 
medium used to provide communications links between 

20 various devices and computers connected within networked 
data processing system 400. Network 402 may include 
permanent connections, such as wire or fiber optic 
cables, or temporary connections made through telephone 
connections . 

25 In the depicted example, server 404 is connected to 

network 402, along with storage unit 406. In addition, 
clients 408, 410, and 412 are also connected to network 
402. These clients, 408, 410, and 412, may be, for 
example, personal computers, network computers, personal 

30 digital assistants, data network compatible cellular 
devices, cable or satellite TV set-top boxes, Internet 
ready game consoles, and the like. For purposes of this 



# • 

Docket No. AUS920010006US1 



application, a network computer is any computer coupled 
to a network which receives a program or other 
application from another computer coupled to the network. 
In the depicted example, server 404 provides data, such 
5 as boot files, operating system images and applications, 
to clients 408-412. Clients 408, 410, and 412 are 
clients to server 404. Networked data processing system 
400 may include additional servers, clients, and other 
devices not shown. 
10 Networked data processing system 400 may be the 

Internet, with network 402 representing a worldwide 
CI collection of networks and gateways that use the TCP/IP 

suite of protocols to communicate with one another. At 
8? the heart of the Internet is a backbone of high-speed 

[fj 15 data communication lines between major nodes or host 

yp computers consisting of thousands of commercial, 

J" government, education, and other computer systems that 

© route data and messages. Of course, networked data 

ru 

processing system 400 also may be implemented as a number 

y} 20 of different types of networks such as, for example, an 

CI 

y :: intranet or a local area network. Figure 4 is intended 

as an example and not as an architectural limitation for 
the processes of the present invention. 

Figure 5 illustrates a block diagram of a data 

25 processing system which may be implemented as a server, 
such as server 404 in Figure 4, in accordance with the 
present invention. Data processing system 500 may be a 
symmetric multiprocessor (SMP) system including a 
plurality of processors 502 and 504 connected to system 

30 bus 506. Alternatively, a single processor system may be 
employed. Also connected to system bus 506 is memory 
controller/cache 508, which provides an interface to 
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local memory 509. I/O bus bridge 210 is connected to 
system bus 506 and provides an interface to I/O bus 512. 
Memory controller/cache 508 and I/O bus bridge 510 may be 
integrated as depicted. Peripheral component 
5 interconnect (PCI) bus bridge 514 connected to I/O bus 

512 provides an interface to PCI local bus 516. A number 
of modems 518-520 may be connected to PCI bus 516. 
Typical PCI bus implementations will support four PCI 
expansion slots or add-in connectors. Communications 
10 links to network computers 408-412 in Figure 4 may be 
provided through modem 518 and network adapter 520 

Q connected to PCI local bus 516 through add-in boards. 

Additional PCI bus bridges 522 and 524 provide interfaces 
for additional PCI buses 526 and 528, from which 

ill 15 additional modems or network adapters may be supported. 

yi In this manner, server 500 allows connections to multiple 

: i z 

S network computers. A memory mapped graphics adapter 530 

S and hard disk 532 may also be connected to I/O bus 512 as 

h ! depicted, either directly or indirectly. 

p| 20 Those of ordinary skill in the art will appreciate 

M= that the hardware depicted in Figure 5 may vary. For 

example, other peripheral devices, such as optical disk 
drives and the like, also may be used in addition to or 
in place of the hardware depicted. The depicted example 
25 is not meant to imply architectural limitations with 
respect to the present invention. The data processing 
system depicted in Figure 5 may be, for example, an IBM 
RISC/System 6000, a product of International Business 
Machines Corporation in Armonk, New York, running the 
30 Advanced Interactive Executive (AIX) operating system. 
Figure 6 illustrates a block diagram of a data 
processing system in which the present invention may be 
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implemented. Data processing system 600 is an example of 
a client computer. Data processing system 600 employs a 
peripheral component interconnect (PCI) local bus 
architecture. Although the depicted example employs a 
5 PCI bus, other bus architectures, such as Micro Channel 
or ISA, may be used. 

Processor 602 and main memory 604 are connected to 
PCI local bus 606 through PCI bridge 608. PCI bridge 608 
may also include an integrated memory controller and 
10 cache memory for processor 602. Additional connections 
to PCI local bus 606 may be made through direct component 
£3 interconnection or through add-in boards. In the 

depicted example, local area network (LAN) adapter 610, 
ffi SCSI host bus adapter 612, and expansion bus interface 

jf'j 15 614 are connected to PCI local bus 606 by direct 

component connection . 

U! 

g" In contrast, audio adapter 616, graphics adapter 

W 618, and audio/video adapter (A/V) 619 are connected to 

M= PCI local bus 606 by add-in boards inserted into 

p! 20 expansion slots. Expansion bus interface 614 provides a 

M s connection for a keyboard and mouse adapter 620, modem 

622, and additional memory 624. 

In the depicted example, SCSI host bus adapter 612 
provides a connection for hard disk drive 626, tape drive 
25 628, CD-ROM drive 630, and digital video disc read only 
memory drive (DVD-ROM) 632. Typical PCI local bus 
implementations will support three or four PCI expansion 
slots or add-in connectors. 

An operating system runs on processor 602 and is 
30 used to coordinate and provide control of various 

components within data processing system 600 in Figure 6. 



# 

Docket No. AUS920010006US1 



The operating system may be a commercially available 
operating system, such as Windows 2000, which is 
available from Microsoft Corporation. Windows is a 
trademark of Microsoft Corporation. In a preferred 
5 embodiment, the operating system is a UNIX-type operating 
system. 

An object oriented programming system, such as Java, 
may run in conjunction with the operating system, 
providing calls to the operating system from Java 
10 programs or applications executing on data processing 
system 600. Instructions for the operating system, the 
^ object-oriented operating system, and applications or 

if} programs are located on a storage device, such as hard 

21 disk drive 626, and may be loaded into main memory 604 

=fc 15 for execution by processor 602. 

Lri 

lP ; Those of ordinary skill in the art will appreciate 

W that the hardware in Figure 6 may vary depending on the 

P implementation. For example, other peripheral devices, 

fU such as optical disk drives and the like, may be used in 

[*§ 20 addition to or in place of the hardware depicted in 
□ Figure 6. The depicted example is not meant to imply 

!=?= 

architectural limitations with respect to the present 
invention. For example, the processes of the present 
invention may be applied to multiprocessor data 

25 processing systems. 

Figure 7 depicts a computer system 700 executing a 
UNIX-based operating system 702, a Java desktop 704, a 
window manager proxy 706, and applications 708 which may 
be native UNIX applications or Java applications in 

30 accordance with the present invention. When the 

application being executed is a Java application, the 
Java desktop provides the window frame processing to 
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provide a particular graphical user interface. When the 
application being executed is a native UNIX application, 
the Java desktop provides the frame window processing, 
and works cooperatively with window manager proxy 706 to 
5 interact with the native UNIX application to provide the 
same graphical user interface. The Java desktop and 
window manager proxy communicate through a Java Native 
Interface (JNI) since the window manger proxy is 
implemented as native UNIX code using the C language. 
10 Those of ordinary skill in the art will recognize that 
the window manager proxy may be implemented in other 
native languages such as C++. 

■ ; i m = 

Figure 8 illustrates a graphical window 800 which 

\s 

^; may be displayed on a display screen to a user m 

by 

4= 15 accordance with the present invention. Graphical window 

^? 800 includes a frame window 802 and an application client 

UJ window portion 804. Frame window 802 is rendered and 

Pi managed by the present invention by Java desktop 704 in 

HJ conjunction with window manager proxy 706. Application 

Lfj 20 client window portion 804 is rendered and managed by 

^ application 708. Window manager proxy 706 does not 

render frame 802 or manage frame events, such as events 
to move or resize frame 802. Window manager proxy 706 
may be called programmatically by applications to change 
25 the position or size of the frame window, and in these 
cases it will forward these events to Java desktop 704 
for processing. Applications display with their frames 
being rendered by the Java desktop, and their client 
windows being rendered by the application. 
30 Figure 9 is a high level flow chart which 

illustrates the setup and starting of a computer system 
which includes a Java desktop and window manager proxy in 
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accordance with the present invention. The process 
starts as depicted by block 900 and thereafter passes to 
block 902 which depicts booting the computer system. 
Next, block 904 illustrates loading a UNIX-type operating 
5 system. Thereafter, block 906 depicts starting the 
window manager proxy. Block 908, then, illustrates 
launching a Java Virtual Machine (JVM) JVM/ Java desktop. 
The process then passes to block 910 which depicts the 
Java desktop notifying the window manager proxy of the 
10 Java desktop's presence in the system. Next, block 912 
illustrates the Java desktop receiving the root window 
handle from the window manager proxy. The process then 
terminates as depicted by block 914. 

Figure 10 is a high level flow chart which depicts a 
Ui 15 process which is followed when a native UNIX application 

w is launched from the Java desktop in accordance with the 

2 %f present invention. The process starts as depicted by 

0 block 1000 and thereafter passes to block 1002 which 

illustrates the action initiated by the user of the Java 
j*i 20 desktop to launch a native application. This action may 

y! be through the use of an icon, menu item, or other user 

interface feature. In response to this action, the 
native application will start and, in accordance with the 
normal startup procedure for an X Windows application, 
25 will communicate with the window manager proxy to get a 
frame window, as depicted by block 1004. The process 
then passes to block 1006 which illustrates the window 
manager proxy communicating with the Java desktop to 
create the frame window. The process then passes to 
30 block 1008 which depicts the Java desktop creating and 
rendering the frame window for the application. 
Thereafter, block 1010 illustrates the window manager 
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proxy managing communications between the frame window, 
application, and the Java desktop. The operation 
depicted by block 1010 is the continuous operation of the 
cooperating elements, the application, window manager 
5 proxy, and Java desktop, that interact to manage the 

frame window and application client window. The process 
then terminates as depicted by block 1012. 

Figure 11 is a high level flow chart which 
illustrates the interaction between the Java desktop, 
10 window manager proxy, and application during user 

interactions with the frame window in accordance with the 
P present invention. The process starts as depicted by 

43 block 1100 and thereafter passes to block 1102 which 

m depicts a user interacting with a frame window by moving 

^: 15 or resizing the frame window. Next, block 1104 

=? i 

.p illustrates the Java desktop rendering the frame at the 

^ new location and/or with the new size. Thereafter, block 

3 1106 depicts the Java desktop determining which 

^ application client window was affected by the change to 

SI 20 the frame window. The process then passes to block 1108 

^ which illustrates the Java desktop calling the window 

manager proxy to notify the application of the move 
and/or resize of its client window. Next, block 1110 
depicts the window manager proxy generating an event to 
25 the application client window. Thereafter, block 1112 
illustrates the application client window refreshing 
itself with the new position and/or size. The process 
then terminates as depicted by block 1114. 

Figure 12 is a high level flow chart which depicts 
30 the execution flow for actions initiated programmatically 
through the window manger proxy from a native UNIX 
application, including events forwarded to the Java 
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desktop, in accordance with the present invention. The 
process starts as depicted by block 1200 and thereafter 
passes to block 1202 which illustrates the window manager 
proxy receiving a native X Windows event. The event type 
will determine the course of action to follow. 
Thereafter, block 1204 depicts a determination of whether 
or not the event is a create event. If a determination 
is made that the event is a create event, the process 
passes to block 1206 which illustrates the window manager 
proxy calling the Java desktop to create a frame window. 
The process then terminates as depicted by block 1222. 

Referring again to block 1204, if a determination is 
made that the event is not a create event, the process 
passes to block 1208 which illustrates a determination of 
whether or not the event is a move event. If a 
determination is made that the event is a move event, the 
process passes to block 1210 which illustrates the window 
manager proxy calling the Java desktop to perform frame 
window move processing. The process then terminates as 
depicted by block 1222. 

Referring again to block 1208, if a determination is 
made that the event is not a move event, the process 
passes to block 1212 which illustrates a determination of 
whether or not the event is a resize event. If a 
determination is made that the event is a resize event, 
the process passes to block 1214 which illustrates the 
window manager proxy calling the Java desktop to perform 
frame window resize processing. The process then 
terminates as depicted by block 1222. 

Referring again to block 1212, if a determination is 
made that the event is not a resize event, the process 
passes to block 1216 which illustrates a determination of 
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whether or not the event is a destroy event. If a 
determination is made that the event is a destroy event, 
the process passes to block 1218 which illustrates the 
window manager proxy calling the Java desktop to perform 
frame window destroy processing. The process then 
terminates as depicted by block 1222. 

Referring again to block 1216, if a determination is 
made that the event is not a destroy event, the process 
passes to block 1220 which illustrates the window manager 
proxy handling the event. The process then terminates as 
depicted by block 1220. 

It is important to note that while the present 
invention has been described in the context of a fully 
functioning data processing system, those of ordinary 
skill in the art will appreciate that the processes of 
the present invention are capable of being distributed in 
the form of a computer readable medium of instructions 
and a variety of forms and that the present invention 
applies equally regardless of the particular type of 
signal bearing media actually used to carry out the 
distribution. Examples of computer readable media 
include recordable-type media, such as a floppy disk, a 
hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and 
transmission-type media, such as digital and analog 
communications links, wired or wireless communications 
links using transmission forms, such as, for example, 
radio frequency and light wave transmissions. The 
computer readable media may take the form of coded 
formats that are decoded for actual use in a particular 
data processing system. 

The description of the present invention has been 
presented for purposes of illustration and description, 
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and is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art. The embodiment was chosen and described in 
order to best explain the principles of the invention, 
the practical application, and to enable others of 
ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are 
suited to the particular use contemplated. 



